home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.342 < prev    next >
Text File  |  1996-02-12  |  29KB  |  611 lines
  1. Frequently Asked Questions (FAQS);faqs.342
  2.  
  3.  
  4.  
  5.   6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?  10BASE-T?
  6.  
  7.      A controversial question.  Some questions & answers from
  8.      the 12/91 BIG-LAN Reader Survey:
  9.  
  10.        "When you install a LAN, which "Technology" (e.g.
  11.        Ethernet, Token Ring) do you prefer?"
  12.  
  13.        37 responders said Ethernet; 2 said "pick one and stick
  14.        with it"; 1 said token ring.
  15.  
  16.        "If you have experience with two or more LAN technologies,
  17.        which have you found works better?"
  18.  
  19.        Answers received:
  20.           "Ethernet works best"                        7
  21.           "Ethernet works better than Token Ring"      4
  22.           "Depends on application"                     1
  23.           "Ethernet works better than ARCnet"          1
  24.           "Ethernet works better than Broadband"       1
  25.           "Ethernet best, Localtalk 2nd, ARCnet 3rd"   1
  26.           "Ethernet works better than PhoneNet"        1
  27.           "Token Ring works best"                      1
  28.  
  29.   7. What is the ideal cable to install in a new building?
  30.  
  31.      Distribution runs, i.e., phone closet to room: Best
  32.      possible thing to do is to leave usable pathways for future
  33.      expansion.  Whatever you do, install at least 2 pair and
  34.      probably 4 pair of data grade unshielded twisted pair.  It
  35.      will always have uses.  Install something else too if you
  36.      are tied to a particular vendor.  Multimode fiber might
  37.      become popular in the future but that is a gamble.
  38.  
  39.      Riser runs, i.e., phone closet to phone closet: it is
  40.      imperative to leave usable pathways for future expansion.
  41.      For Ethernet, ThinWire is a usable riser cable, multimode
  42.      fiber is possible too.
  43.  
  44.   8. What is the ideal cable to install between buildings on a campus?
  45.  
  46.      Trunks, i.e., cables into the building: pathways for future
  47.      expansion very valuable.  Multimode fiber is useful, run 24
  48.      fibers if you can.  Use cable with some single mode too.
  49.      Run several times what you need initially and leave a lot
  50.      of the unused fiber unterminated for the time being.  Cable
  51.      pulling & termination are much more costly than the cable
  52.      itself.
  53.  
  54.   9. Whose routers are recommended?
  55.  
  56.      Question & answer from the 12/91 BIG-LAN Reader Survey:
  57.  
  58.        "Name some router vendors whose routers you have used and
  59.        recommend:"
  60.  
  61.        Cisco got 30 mentions; Wellfleet 4; PCRoute 2; Proteon 2;
  62.        Apple 1; DEC 1; Network Systems 1; Shiva 1; Vitalink 1;
  63.        3COM 1.
  64.  
  65.   10. Whose bridges are recommended?
  66.  
  67.      Question & answer from the 12/91 BIG-LAN Reader Survey:
  68.  
  69.        "Name some bridge vendors whose routers you have used and
  70.        recommend:"
  71.  
  72.        DEC got 6 mentions; Retix 5; BICC 3; Cabletron 3; 3COM 3;
  73.        Cisco 2; PCBridge 2; Vitalink 2; ACC 1; Clearpoint 1;
  74.        Datability 1; Develcon 1; Dowty Scanet 1; HP 1; IBM (Token
  75.        Ring) 1; Network Application Technology 1; PCBRoute 1;
  76.        Wellfleet 1.
  77.  
  78.   11. Whose Ethernet equipment are recommended?
  79.  
  80.      Question & answer from the 12/91 BIG-LAN Reader Survey:
  81.  
  82.        "Name some Ethernet concentrator/transceiver/repeater
  83.        vendors whose Ethernet equipment you have used and
  84.        recommend:"
  85.  
  86.        Cabletron got 20 mentions; BICC 8; DEC 8; HP 4; Synoptics
  87.        4; David 3; Lantronix 3; Gandalf 2; Lannet 2; Pirelli Focom
  88.        2; Acton 2; Allied Telesys 1; AMP 1; Asante 1; Chipcom 1;
  89.        Dowty Scanet 1; Dupont Electroptic 1; EAZY 1; Fibermux 1;
  90.        Hirschmann 1; IMC Network Corporation 1; NetCor
  91.        Transceivers 1; Sension 1; 3COM 1.
  92.  
  93.   12. Whose Token Ring equipment are recommended?
  94.  
  95.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  96.  
  97.        "Name some Token Ring equipment vendors whose Token Ring
  98.        equipment you have used and recommend:"
  99.  
  100.        IBM was mentioned by 6 responders; FiberMux 1; Madge 1;
  101.        Synoptics 1.
  102.  
  103.   13. Whose FDDI equipment are recommended?
  104.  
  105.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  106.  
  107.        "Name some FDDI equipment vendors whose FDDI equipment you
  108.        have used and recommend:"
  109.  
  110.        Cisco was mentioned by 6 responders; DEC 2; Tymeplex 2;
  111.        ALCATEL 2; AT&T 1; Synernetics 1; Tekelec 1.
  112.  
  113.   14. What PC network software is recommended?
  114.  
  115.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  116.  
  117.        "Name some PC network software vendors whose PC network
  118.        software you have used or recommend:"
  119.  
  120.        Novell was mentioned by 19 responders; FTP Software 14; Sun
  121.        8; DEC 3; Apple 2; Farallon 2; InterCon 2; 3COM 2; Beame
  122.        and Whiteside 1; Hummingbird Communications 1; IBM 1;
  123.        Microsoft 1; NCSA 1; Neon Software 1; Network Application
  124.        Technology 1; Sitka 1.
  125.  
  126.   15. What protocols should run on a campus-wide LAN?
  127.  
  128.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  129.  
  130.        "Name some protocols that you use to interconnect your
  131.        campus that you would recommend:"
  132.  
  133.        TCP/IP was mentioned by 39 responders; Appletalk 9; DECNET
  134.        9; IPX 9; LAT 2; Coloured Book 2; G.703 2; ISO CONS 2;
  135.        X.25/HDLC 1; XNS 1.
  136.  
  137.   16. What software is recommended for managing a campus-wide LAN?
  138.  
  139.      Queries and answers from the 12/91 BIG-LAN Reader Survey:
  140.  
  141.        "Name some network management system that you use for the
  142.        management of a campus LAN, that you recommend:"
  143.  
  144.        PSI SNMP was mentioned by 4 responders; Cabletron Remote
  145.        LanView 2; Cisco NetCentral 2; Proteon Overview 2; SNMP 2;
  146.        "A good drawing program" 1; DEC EMA 1; Map 1; NEMISYS from
  147.        SEEL 1; SunNet Manager 1; TRW NMS 1.
  148.  
  149.        "Name other software that you use for the management of a
  150.        campus LAN that you recommend:"
  151.  
  152.        FTP LanWatch was mentioned by 3 responders; EtherPeek 2;
  153.        ping 2; AG Group Net Watchman for Appletalk 1; Apple
  154.        Interpoll 1; Clarkson Packet Driver Utilities 1; DEC LAN
  155.        Traffic Monitor 1; Domain Name System 1; inetrover 1; LAN
  156.        Patrol 1; Neon Software Netminder Localtalk 1; Neon
  157.        Software Netminder Ethernet 1; Network Application
  158.        Technology EtherMeter 1; Shiva Net Manager 1; SNMP-Gawk (A
  159.        SNMP-capable Gawk) 1; traceroute 1; Unix 1; Watchdog 1.
  160.  
  161.   17. What terminal server is recommended?
  162.  
  163.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  164.  
  165.        "Name vendors of terminal servers that you use and
  166.        recommend:"
  167.  
  168.        Cisco was mentioned by 13 responders; DEC 5; Xyplex 4;
  169.        Datability 2; Xylogics 2; 3COM 2; Emulex 1; Lantronix 1;
  170.        Netcomm 1; Spider 1; TRW 1.
  171.  
  172.   18. Whose troubleshooting equipment are recommended?
  173.  
  174.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  175.  
  176.        "Name some vendors of network troubleshooting equipment
  177.        that you use and would recommend:"
  178.  
  179.        Network General was mentioned by 8 responders; HP 4;
  180.        Tektronix 4; Cabletron 3; Novell 3; Spider 3; AG Group 2;
  181.        Wandel and Goltermann 2; FOTEC 1; Neon Software 1.
  182.  
  183.   19. What security products should I buy?
  184.  
  185.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  186.  
  187.        "Name some security products that you use to maintain
  188.        security on your campus LAN that you recommend:"
  189.  
  190.        The answers reflected the lack of obvious products to
  191.        choose from.  Responses included "Athena Kerberos",
  192.        "Encryption in Net3270", "Extended TACACS', "Host
  193.        security", "Physical security", "Router access control
  194.        lists", "SecurID", "Virus Scan", and "Windows Workstation".
  195.  
  196.   20. Should the names of devices on my campus LAN have subdomains?
  197.  
  198.        Example of name without subdomain: bigvax.sequoia.edu;
  199.        example with subdomain: bigvax.acs.sequoia.edu.  It is
  200.        possible to run networks of thousands of computers without
  201.        the bother of subdomains, but they have some advantages.
  202.  
  203.      Queries and answers from the 12/91 BIG-LAN Reader Survey:
  204.  
  205.        "For Internet names of nodes on a campus network that
  206.        supports TCP/IP, do you prefer the use of subdomains?"
  207.  
  208.        27 responders said yes, 5 said no, 2 said it depends.
  209.  
  210.        "If you have worked on a campus that utilizes subdomains
  211.        and one that does not, which does your experience tell you
  212.        is the better way to administer names in a campus network?"
  213.  
  214.        5 responders said the LAN with subdomains worked better; 2
  215.        said the LAN without subdomains worked better.  One
  216.        responder claimed that a good rule of thumb is that a LAN
  217.        with more than 4000 stations works better with subdomains.
  218.  
  219.   21. Should client stations use POP?  Should they use just
  220.       SMTP?  Should I use some non-TCP/IP protocol for mail
  221.       to/from client stations?
  222.  
  223.      Query and answers from the 12/91 BIG-LAN Reader Survey:
  224.  
  225.        "For client station's mail, which do you prefer: SMTP;
  226.        TCP/IP-based client-server protocols (e.g.  POP, POP2,
  227.        etc); other LAN protocols?"
  228.  
  229.        10 responders preferred TCP/IP-based client-server
  230.        protocols (e.g.  POP, IMAP, PCMAIL); 7 preferred SMTP; 4
  231.        said "use all three"; 3 preferred users signing onto a host
  232.        system; 2 preferred other LAN protocols; 1 said "SMTP and
  233.        TCP/IP-based client-server protocols"; 1 said "SMTP and
  234.        X.400".
  235.  
  236.  
  237.   22. Should I enable SQE/heartbeat?
  238.  
  239.      This is a very brief discussion of SQE and CPT (both commonly
  240.      referred to as "heartbeat") for IEEE 802.3 and Ethernet.  For
  241.      really gory details, see the appropriate documents, IEEE
  242.      standard 802.3, ISO standard 8802-3, and the DIX Ethernet V2
  243.      Standard.  (The first 2 references are, in theory, identical.)
  244.  
  245.      First, SQE and CPT are not quite the same thing.  CPT is a part
  246.      of DIX Ethernet Version 2 and is simply a test of collision
  247.      detection functionality in the MAU (that's the correct name for
  248.      a transceiver, Media Access Unit).  It is ALWAYS present in
  249.      Ethernet V2 MAUs and can't ever be disabled (without modifying
  250.      the hardware).  It is required for correct operation of ALL
  251.      Ethernet V2 equipment.
  252.  
  253.      SQE, on the other hand, is part of the 802.3 specification and
  254.      performs basic MAU tests and "reports" to the controller if all
  255.      is well.  The "report" is in the form of a pulse nearly
  256.      identical to the V2 CPT pulse, but with slightly differing
  257.      timing specifications.  It should be switchable, as 802.3
  258.      requires SQE for all terminal equipment, but prohibits it for
  259.      repeaters.
  260.  
  261.      SQE and Heartbeat both appear as a signal in the collision lines
  262.      from the MAU to the controller after every write.  This is why
  263.      MAUs with SQE enables and with displays show a collision every
  264.      time they show a write.  THIS IS NORMAL!
  265.  
  266.      Quick digression: What is a collision?  Of course, we all know
  267.      that a collision is when two controllers start to transmit at
  268.      the same time (more of less) and that when this happens both
  269.      will stop and wait for a random interval and then retransmit if
  270.      carrier is not present.  This function is critical to proper
  271.      network operation.  A MAU which can't detect a collision can
  272.      mess up a network badly.  This makes it critical to be able to
  273.      quickly isolate "broken" MAUs.  If you don't understand this,
  274.      read any of the old papers on multiple access nets, especially
  275.      the old Aloha Net.  Collisions are a normal part of Ethernets.
  276.      There is nothing "wrong" with having collisions.  The name seems
  277.      to make people think that they are somehow bad.  If you start to
  278.      feel that way, say to yourself 20 times before going to be
  279.      tonight: "Collisions are my friend."
  280.  
  281.      Having said all of that, there is one type of collision that is
  282.      NOT your friend.  The "Late Collision".  This is a collision
  283.      which is generated more than 60 bytes into a packet.  Since the
  284.      is "impossible", it indicates that something is seriously wrong.
  285.      Too long a cable, a bad MAU, or some other hardware problem.  IF
  286.      you are getting late collisions, you are also likely corrupting
  287.      packets without knowing it because collisions are not being
  288.      properly detected.
  289.  
  290.      In practice, MAUs hardly ever fail.  BUT IF ONE DOES, YOU MAY
  291.      HAVE A BIG PROBLEM!
  292.  
  293.      While SQE indicates a bit more than heartbeat did and is
  294.      slightly different in both timing and electrical
  295.      characteristics, they are essentially the same from the
  296.      perspective of most terminal equipment and you can replace an
  297.      Ethernet V2 MAU with an 802.3 MAU with SQE enabled most of the
  298.      time.  (A notable exception is an Ethernet repeater which really
  299.      requires an Ethernet V2 MAU.  There may be others.) You can even
  300.      replace an 802.3 MAU with an Ethernet V2 one most of the time.
  301.      In fact, there are "fixes" for some Ethernet V2 MAUs to disable
  302.      heartbeat and make them into something like an 802.3 MAU with
  303.      SQE disabled.  This also seems to work almost all the time.
  304.  
  305.      Anyone still with me?  OK.
  306.  
  307.      RULE FOR SQE.  Always turn it on except for repeaters.  There
  308.      should be no exceptions to this rule, but there are.  Some
  309.      manufacturers can't seem to read standards (or just don't care).
  310.      As a result there are some terminal devices that get upset when
  311.      they see SQE.  I have been told that this is true of the cisco
  312.      AGS, but not the IGS; not that there is any documentation on
  313.      this.  Several email exchanges with cisco folks have not
  314.      clarified this.
  315.  
  316.      There is one BIG special case, the Etherrnet fan-out box, most
  317.      commonly a DEC DELNI.  This box has only one MAU, so it repeats
  318.      the CPT (it's a V2 device) that it sees from the MAU on the
  319.      "master" port.  If the master port is disabled, CPT is generated
  320.      internally to keep things happy.
  321.  
  322.      But, what if you plug a repeater into a DELNI?  You can disable
  323.      CPT by using an 802.3 MAU with SQE disabled.  or, if you don't
  324.      use the master port, turn it on and plug an Ethernet loopback
  325.      connector into the master port.  In either case, CPT is disabled
  326.      to ALL PORTS!  No way around this.
  327.  
  328.      DELNIs produce other oddities.  They reduce the maximum segment
  329.      length on segments connected to the master port to 300 meters
  330.      and shorten the maximum length of the AUI cable used between the
  331.      system and the DELNI by 5 meters.  (And don't forget to include
  332.      the length of the cable between the interface and the connector
  333.      on the rear of the cabinet.) Because of these and other
  334.      oddities, I try to avoid DELNIs.  And I NEVER EVER plug a
  335.      repeater of any type into one.
  336.  
  337.      Other companies make 802.3 equivalents to the DELNI on which SQE
  338.      may be switched on each port.  While this fixes one problem, the
  339.      timing concerns of fan-out boxes remains.  Buyer beware!
  340.      Neither 802.3 nor Ethernet V2 standards cover fan-out boxes in
  341.      any way, so there is no way to really claim that they meet
  342.      standards (or don't).
  343.  
  344.      We've now covered the basics.  So what happens when a MAU fails?
  345.      In theory, every time it transmits a packet, an error is logged.
  346.      This happens on some equipment.  But most software I've dealt
  347.      with simply ignores the error flag and does nothing.  So SQE
  348.      makes absolutely no difference to these systems.  THIS IS BAD
  349.      SOFTWARE DESIGN.
  350.  
  351.      Once in a while a MAU does fail.  If it is on some device that
  352.      does not log SQE failures or has a MAU with SQE turned off, you
  353.      don't know what is happening.  If you are on 10BASE-T, it can be
  354.      isolated to a hub pretty quickly, but on coax you are reduced to
  355.      segmenting the cable (physically disconnecting it) until you
  356.      have isolated the problem.  This is NOT fun and makes the
  357.      network manager very unpopular since the network tends to be
  358.      down for a LONG time.  It took about 4 hours last time I had
  359.      this problem and could have taken longer.
  360.  
  361.      What's a network manager supposed to do?  Complain vigorously to
  362.      vendors of equipment that don't adhere to the standard.
  363.      Complain equally to vendors of software that doesn't bother to
  364.      log the failures.  SNMP is no good if the agents don't have any
  365.      information to send out.
  366.  
  367. End of Memo: BIG-LAN Frequently Asked Questions
  368. Xref: bloom-picayune.mit.edu comp.mail.misc:10271 news.answers:3545
  369. Newsgroups: comp.mail.misc,news.answers
  370. Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!micro-heart-of-gold.mit.edu!wupost!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!newstand.syr.edu!spider.syr.EDU!jmwobus
  371. From: jmwobus@mailbox.syr.edu (John Wobus)
  372. Subject: LAN Mail Protocols Summary
  373. Message-ID: <1992Oct16.133537.19263@newstand.syr.edu>
  374. Followup-To: poster
  375. Originator: jmwobus@spider.syr.EDU
  376. Reply-To: jmwobus@mailbox.syr.edu
  377. Organization: Syracuse University, Syracuse, NY
  378. Date: Fri, 16 Oct 92 13:35:37 EDT
  379. Approved: jmwobus@mailbox.syr.edu
  380. Lines: 198
  381.  
  382. Archive-name: LANs/mail-protocols
  383.  
  384. Serving PCs and Workstations Using a Central Mail Server on an Internet
  385. ------- --- --- ------------ ----- - ------- ---- ------ -- -- --------
  386.  
  387. There are advantages to collecting mail destined to PCs and
  388. workstations on a central server, to be turned over to the PC or
  389. workstation on demand:
  390.  
  391. - Your PC or workstation may be down quite a bit and less network
  392.   bandwidth and less of the processing resouces of the sending computer
  393.   are used if the computer receiving your mail is ready.
  394. - Some people use more than one PC or workstation to read mail.
  395. - A PC or workstation may not have the resources to store all the mail
  396.   you receive.
  397. - It can make your e-mail address more like other users'.
  398.  
  399. The easiest way to "implement" this is to run the central mail server
  400. like any multi-user system: let people sign on to it and use some mail
  401. utility.  Then PC and workstation users can use "terminal sessions" to
  402. sign on to the central mail server and read their mail.  This has the
  403. disadvantage of making the PC and workstation users learn and use the
  404. central mail server's procedures.
  405.  
  406. SMTP, the "internet" mail protocol used to deliver mail between
  407. multi-user systems only supports mail transfer initiated by the
  408. sender.  Other protocols have been devised to allow a workstation or PC
  409. to request transfer of mail, thus able to make use of a cnetral
  410. server.  These include the published protocols POP (probably not used
  411. anymore), POP2, POP3, IMAP2, IMAP3 and DMSP.
  412.  
  413. POP, POP2, POP3:  These are rather minimal and are designed to be so.
  414. The three are similar but not enough alike to be interoperable.  They
  415. are basically designed to identify the user by username and password,
  416. to transfer the mail from server to PC or workstation and to delete the
  417. mail transferred.  It is assumed that SMTP will be used to send mail.
  418. Messages can be retrieved individually, but the only information you
  419. can get about a message without transferring it is its length in
  420. bytes-- useful for PCs with limited storage.
  421.  
  422. POP2 and POP3 are still used a good deal.  POP3 has a couple of
  423. optional extensions: one to avoid sending passwords, and one to aid in
  424. reading bulletin boards.
  425.  
  426. IMAP2, IMAP3:  The IMAP family is similar to the POP family, but also
  427. gives clients a way to do string searches through mail that still
  428. resides on the server.  This is designed to allow the PC or workstation
  429. to be more selective as to which mail will be transferred.  The POP
  430. protocols, on the other hand, are designed for simpler server
  431. software.
  432.  
  433. IMAP2 is used quite a bit.  IMAP3 is an incompatible offshoot that has
  434. not been implemented much.  Recent work not yet documented in an RFC
  435. has extended IMAP2 to include support for multimedia mail.
  436.  
  437. DMSP (aka PCMAIL):  PCs and workstations can use this protocol to both
  438. send and receive mail.  The system is designed around the idea that
  439. each user can own more than one workstation; however, the system
  440. doesn't seem to handle the idea of a "public workstation" very well.
  441. The PCs and workstations are assumed to hold state information about
  442. the mail, a directory so to speak, and when the PC or workstation is
  443. connected to the server, this directory is updated to "reality".
  444.  
  445. More about the protocols:
  446.  
  447. Name:      Post Office Protocol, Version 2
  448. Nickname:  POP2
  449. Document:  RFC 937 (Butler et al, February 1985)
  450. TCP-port:  109
  451. Sites:
  452.  
  453. Name:      Post Office Portocol, Version 3
  454. Nickname:  POP3
  455. Document:  RFC 1225 (Rose, May 1991)
  456. TCP-port:  110 (109 also often used)
  457. Sites:     UC Irvine, MIT
  458.  
  459. Name:      Distributed Mail Service Protocol
  460. Nickname:  DMSP, Pcmail
  461. Document:  RFC 1056 (Lambert, June 1988)
  462. TCP-port:  158
  463. Sites:     MIT
  464.  
  465. Name:      Interactive Mail Access Protocol, Version 2
  466. Nickname:  IMAP2
  467. Document:  RFC 1176 (Crispin, August 1990)
  468. TCP-port:  143
  469. Sites:     Stanford, U Washington
  470.  
  471. Name:      Interactive Mail Access Protocol, Version 3
  472. Nickname:  IMAP3
  473. Document:  RFC 1203 (Rice, February 1991)
  474. TCP-port:  220
  475. Sites:     Stanford
  476.  
  477. Implementations:
  478.  
  479. Prot   Computer    Implementation      End     Source
  480. ------ ----------- ------------------- ------- --------------------------------
  481. DSMP   PC          pc-epsilon (3.1)    client  allspice.lcs.mit.edu
  482. DSMP   PC          pc-netmail (3.1)    client  allspice.lcs.mit.edu
  483. DSMP   PC          pc-reader           client  allspice.lcs.mit.edu
  484. DSMP   Unix        Pcmail 3.1 reposit. server  allspice.lcs.mit.edu
  485. DSMP   Unix/EMACS  Pcmail 4.2          client  allspice.lcs.mit.edu
  486. DSMP   PC          PC/TCP              client  FTP Software
  487. DSMP   OS/2        PC/TCP              client  FTP Software
  488. DSMP   OS/2        TCP/2               client  Essex Systems
  489. DSMP   OS/2        TCP/2 SERVER PACK   server  Essex Systems
  490. DSMP   OS/2        TCP/2 ADV CLIENT    client  Essex Systems
  491. IMAP2  Macintosh   MacMS 2.2.1         client  sumex-aim.stanford.edu
  492. IMAP2  Macintosh   Mailstrom (beta)    client  sumex-aim.stanford.edu
  493. POP2   Macintosh   MacPOP 1.5          client  trident.arc.nasa.gov
  494. POP2   MS-DOS      PC POP 2.1          client  trident.arc.nasa.gov
  495. POP3   Macintosh   TCP/Connect II      client  InterCon Systems Corporation
  496.  
  497. IMAP2  NeXT        EasyMail            client  ftp.cac.washington.edu
  498. IMAP2  NeXT        MailManager         server  ftp.cac.washington.edu
  499. IMAP2  TOPS20      ?                   server  ?
  500. IMAP2  Unix        ?                   client  ftp.cac.washington.edu
  501. IMAP2  Unix        imapd 3.1           server  sumex-aim.stanford.edu*
  502. IMAP2  Unix/X      ximap 0.7.2         client  sumex-aim.stanford.edu
  503. IMAP2  Unix        imapd               server  ftp.cac.washington.edu
  504. IMAP2  Unix        pine                client  ftp.cac.washington.edu
  505. IMAP2  Xrx Lsp Mch ?                   client  ?
  506. IMAP2  MS-DOS      pine (future)       client  ?
  507. IMAP2  MS-Windows  ?                   client  ?Some company in Canada
  508. POP2   Macintosh   POPMail II          client  boombox.micro.umn.edu
  509. POP2   Macintosh   MailStop            server  boombox.micro.umn.edu
  510. POP2   MS-DOS      LifeLine Mail       client  SunSelect
  511. POP2   MS-DOS      ka9q                server  ucsd.edu
  512. POP2   MS-DOS      MD/DOS-IP           client  U Maryland
  513. POP2   MS-DOS      PC/TCP              client  FTP Software
  514. POP2   Unix        ?                   server  boombox.micro.umn.edu
  515. POP2   Unix        popd (USC-ISI)      server  trident.arc.nasa.gov
  516. POP2   Unix        imapd/ipop2d        server  ftp.cac.washington.edu
  517. POP2   Unix        mh-6.7 (UCI RandMH) server  ftp.cc.berkeley.edu
  518. POP2   VM          FAL                 server  IBM
  519. POP2   VM          ?                   server  Texas Tech University
  520. POP2   OS/2        TCP/2 SERVER PACK   server  Essex Systems
  521. POP2   VMS         MULTINet            server  TGV, Inc.
  522. POP3   Macintosh   Eudora 1.2.2        client  ftp.cso.uiuc.edu
  523. POP3   Macintosh   Eudora 1.3 (in dev) client  Not Yet
  524. POP3k  Macintosh   Eudora X            client  run at Brown U.
  525. POP3   Macintosh   MacPOP (Berkeley)   client  ftp.cc.berkeley.edu
  526. POP3k  Macintosh   TechMail 2.0        client  net-dist.mit.edu
  527. POP3   Macintosh   MacMH               client  jessica.stanford.edu/info
  528. POP3   Macintosh   POPMail II          client  boombox.micro.umn.edu
  529. POP3   Macintosh   MailStop (soon)     server  UMinn
  530. POP3t  Unix        popper-1.7          server  ftp.cc.berkeley.edu
  531. POP3   Unix        popper-1.831        server  ?
  532. POP3   Unix        mh-6.7 (UCI RandMH) both    ics.uci.edu
  533. POP3   Unix        imapd/ipop3d        server  ftp.cac.washington.edu
  534. POP3t  MS-DOS      PC/TCP              client  FTP Software
  535. POP3   MS-DOS      TechMail(future)    client  ?
  536. POP3   MS-DOS      ?                   client  logos.ucs.indiana.edu
  537. POP3   MS-DOS      NUPOP (in beta)     client  (ftp.acns.nwu.edu)
  538. POP3   MS-DOS      POPMail/PC          client  boombox.micro.umn.edu
  539. POP3   MS-DOS      Eudora (alpha)      client  Qualcomm Inc (pc-eudora-info@qualcom.com)
  540. POP3   MS-DOS      ka9q (future)       server  ?
  541. POP3   ?           POPgate (Pmail gw)  server  risc.ua.edu
  542. POP3x  MSwindows   WinQVT (2.1)        client  QPC Software (shareware)
  543. POP3   MSwindows   Eudora (future)     client  Qualcomm Inc (pc-eudora-info@qualcom.com)
  544. POP3   MSwindows   wnqvtnet            client  ftp.cica.indiana.edu
  545. POP3   VMS         IUPOP3 (1.7) (1.6?) server  mythos.ucs.indiana.edu, logos?
  546. POP3   VMS         MULTINet            both    TGV, Inc.
  547. POP3   OS/2        TCP/2 SERVER PACK   server  Essex Systems
  548. POP3   OS/2        TCP/2 ADV CLIENT    client  Essex Systems
  549. POP?   MS-DOS      UCDmail             client  ucdavis.ucdavis.edu
  550. POP?   MS-DOS      PC POP              client  ?Bill Schweickert/Sterling Fed
  551. POP?   Macintosh   MEWS                client  ?
  552. POP?   Macintosh   byupopmail          client  ?
  553. POP?   VM          ?                   server  TTUVM1
  554. ?      Macintosh   Hypermail           ?       ?
  555. ------ ----------- ------------------- ------- --------------------------------
  556. Appendix:
  557. Some other packages for desktop systems
  558. ------ ----------- ------------------- ------- --------------------------------
  559. uucp   Macintosh   uAccess             peer    ICE Engineering
  560. SMTP   Macintosh   LeeMail 1.2.4       peer    Shareware, laf@mitre.org
  561. uucp   Macintosh   FernMail            peer    Shareware, dplatt@snulbug.mtview.ca.us
  562. prop   Macintosh   MacPost             both    ftp.lu.se
  563. uucp   Macintosh   Eudora              peer    ftp.cso.uiuc.edu
  564. uucp   Macintosh   UUPC                peer    dplatt@snulbug.mtview.ca.us
  565. uucp   Macintosh   gnuucp              peer    jim@fpr.com
  566. ?      MS-DOS      Pmail 2.3 (R1)      client  splicer.cba.hawaii.edu
  567. ?      MS-DOS      Pmail 2.3 (R2)(fut) client
  568. ?      MS-Windows  Pmain/Windows (fut) client
  569. ?      Macintosh   Pmail/Mac 1.1       client  splicer.cba.hawaii.edu
  570. ?      Macintosh   Pmail/Mac 2.0(beta) client  risc.ua.edu
  571. ------ ----------- ------------------- ------- --------------------------------
  572. Other issues:
  573. (1) What are the common extensions to POP3 and which clients/servers
  574.  support them?
  575. POP3k - kerberos
  576. POP3x - ?
  577. POP3t - xtnd xmit facility--allows client to send mail through additional
  578.  POP commands, thus allowing server to verify/log source of mail.
  579. ------ ----------- ------------------- ------- --------------------------------
  580. Xref: bloom-picayune.mit.edu comp.os.linux.announce:37 comp.os.linux:20812 news.answers:4588
  581. Newsgroups: comp.os.linux.announce,comp.os.linux,news.answers
  582. Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!xn.ll.mit.edu!ames!saimiri.primate.wisc.edu!caen!batcomputer!db.TC.Cornell.EDU!mdw
  583. From: mdw@db.TC.Cornell.EDU (Matt Welsh)
  584. Subject: [comp.os.linux.announce] Guidelines for posting
  585. Message-ID: <1992Dec14.202427.14323@tc.cornell.edu>
  586. Followup-To: poster
  587. Keywords: announce posting guidelines
  588. Sender: news@tc.cornell.edu
  589. Nntp-Posting-Host: db.tc.cornell.edu
  590. Organization: The Linux Inquisition, Propaganda Division
  591. Date: Mon, 14 Dec 1992 20:24:27 GMT
  592. Approved: linux-announce@tc.cornell.edu (Matt Welsh)
  593. Lines: 111
  594.  
  595. Archive-name: linux-faq/announce/guide
  596. Last-modified: 6 Dec 1992
  597.  
  598. HOW TO POST TO COMP.OS.LINUX.ANNOUNCE
  599.  
  600. This article gives info on how and what to post to comp.os.linux.announce.
  601. Please read the whole thing, to avoid any confusion. :)
  602.  
  603. To submit an article to this group, please mail the article to:
  604.     linux-announce@tc.cornell.edu
  605.  
  606. If you have questions or problems with posting to comp.os.linux.announce,
  607. please send mail to the moderators at:
  608.     linux-announce-request@tc.cornell.edu
  609. Or, you may send mail to us directly. The moderators for this group are
  610. Matt Welsh (mdw@tc.cornell.edu) and Lars Wirzenius (wirzeniu@cc.helsinki.fi).
  611.